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[57] ABSTRACT 

A remote data base containing flight schedule, fare, and 
fare limitations information is accessed from a local 
computer terminal. The information retrieved is sorted 
and scored in accordance with a predetermined travel 
policy stored in the local computer memory, and as 
applied to a proposed travel itinerary. A ranked list of 
applicable flights is merged into a single display. 
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COMPUTER RESERVATION SYSTEM WITH 
MEANS TO RANK TRAVEL ITINERARIES 
CHOSEN IN TERMS OF SCHEDULE/FARE DATA 

5 

TECHNICAL FIELD 

This invention relates to data processing methodol- 
ogy and apparatus for accessing flight scheduling, fare, 
and fare limitations information and sorting and scoring 
selected flight schedules and fares from the accessed 
information in accordance with a predetermined travel 
policy. 

BACKGROUND ART 

Deregulation of the airline industry has resulted in 
the proliferation of varied flight schedules and fares, 
each with its own particular set of eligibility require- 
ments. Electronic data base services have assisted in the 
dissemination of flight schedule and fare information, 
but the effectiveness of such data availability has been 
limited by its own unmanageable volume. While some 
companies have developed general travel policies in an 
attempt to take advantage of competitive flight fares, it 
has heretofore been difficult to apply a given travel 25 
policy to the overwhelming quantity of flight schedul- 
ing and fare information. A system that could access 
flight, scheduling and fare information, and automati- 
cally apply a predetermined travel policy to select the 
preferred travel itinerary from the accessed information 
would be a decided advantage. 

SUMMARY OF THE INVENTION 

The problems outlined above are in large measure 
solved by the present invention. The system disclosed 35 
herein provides means for accessing stored flight infor- 
mation, and a method for sorting and scoring the data so 
received in accordance with a predetermined travel 
policy. Unacceptable or unavailable flights can be pre- 
screened, and travel policy considerations such as flight 4Q 
time, airline preference, ground transportation costs 
associated wi^ particular airports, and layover require- 
ments can be applied to acceptable and available flights 
for scoring and selection of the best available flight. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is a schematic view of a system in accordance 
with the present invention; 

FIG. 2 is a logical flow diagram showing the overall 
operation of the present invention; 50 

FIG. 3 is a flow chart depicting in greater detail the 
data access and read step 44 of FIG, 2; 

FIGS. 4fl-l, 4fl-2 and 46 represent a flow chart depict- 
ing in greater detail the retrieve flight information step 
60 of FIG. 3; 55 

FIGS. 5fl-l, 5g-2, Sb'l and 56-2 represent a flow chart 
depicting in greater detail the retrieve fares step 118 of 
FIG. 46; 

FIG. 6 is a flow chart depicting in greater detail the 
retrieve and evaluate limitation step 164 of FIG. 5; 60 

FIG. 7 is a flow chart depicting in greater detail the 
evaluate limitation step 190 of FIG. 6; 

FIG. 8 is a flow chart depicting in greater detail the 
sort and display step 48 of FIG. 2; 

FIG. 9 is a flow chart depicting in greater detail the 65 
generate score values step 218 of FIG. 8; and 

FIG. 10 is a flow chart depicting in greater detail the 
summarize itinerary step 224 of FIG. 8. 



DETAILED DESCRIPTION OF THE 
DRAWINGS 

Referring to the drawings, a system for accessing and 
processing remotely stored flight travel data 20 includes 
a locally operated computer system 21 having terminal 
22 rhemory storage disk 24 for storing travel policy 
information, printer 26, and communications modem 28. 
Modem 28 is connected via land lines 30 to a remotely 
maintained computer system 32. The computer system 
32 includes communications interface equipment 34, 
computer 36, and a plurality of memory storage disks 
38, 40, 42, The remote computer data base is preferably 
a compendium of travel schedule and fare information, 
such as the Official Airline Guides Electronic Edition, 
maintained by Official Airline Guides, Inc. of 2000 
Clearwater Drive, Oak Brook, Illinois 60521. While the 
system is shown in conjunction with a remote data base, 
it will be understood that the sorting and scoring func- 
tion of the system could be applied to locally stored 
flight information. 

Referring to FIG. 2, operation of the system 20, in its 
broadest sense, is depicted in flow chart form. The 
operator of the system 20 inputs a starting location and 
final destination, together with any desired intermediate 
stops, at the local computer terminal (step 42). The 
operator next presses a connect key (step 44), thereby 
connecting the local computer system 21 to the remote 
computer system 32. Flight scheduling information fare 
information, and flight/fare limitation information 
stored in the remote computer system data base can be 
read by the local computer system 21, step 46. Once the 
scheduling, fare, and limitation information is received, 
the information is sorted and displayed in accordance 
with the travel policy information stored on disk stor- 
age 24, step 48. Once displayed, the operator can select 
flights recommended by the travel policy software, and 
can print hard copy reports on printer 26, step 50. 

The system connect and read information step 46 of 
FIG, 2 is set out in greater detail in FIG. 3, Communica- 
tions with the remote data base service must first be 
established, step 52. In particular, the phone number, 
baud rate, account number, password, and other perti- 
nent information needed to establish communications 
are stored in the local computer terminal, and are used 
in conjunction with modem 28 to establish communica- 
tions. Once communications are established, step 54 is 
undertaken to query the remote data base for the valid- 
ity of each city name entered by the operator at the 
local terminal. In particular, the cities entered by the 
operator in step 42 are checked against the city codes in 
the remote data base to ensure that the entries input by 
the operator find correspondence in the data base. Also, 
in cases' where more than one city has the same name, 
the several alternatives are presented to the operator for 
selection of the desired city. 

Step 56 uses the term "city pair". A city pair com- 
prises a starting and ending point of one leg of a jour- 
ney, A connecting stop in an intermediate city is not 
considered a starting or ending point of one leg of a 
journey. The final leg of a trip (the last city pair) is 
selected in step 56, for examination of the scheduling, 
fare, and fare limitation information for that last city 
pair before the same information relating to the next 
previous city pair is examined. 

Valuable data processing time is saved by considering 
the last city pair first. The process time saving is based 
on the premises that most travelers return to their origi- 
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nating place of travel, and that many of the lowest 
airline fares are based on making a round trip on one 
carrier, at the same fare class. Once the round trip fare 
classes and availability information for the return legs of 
possible round trip pairs in the trip have been gathered, 5 
the flights and fares for previous city pairs in a particu- 
lar itinerary can be quickly scanned to determine 
whether they can combine with a return city pair leg in 
a round trip for a round trip fare. If an outgoing flight 
in a preceding city pair cannot be combined with an 10 
incoming flight in a following city pair to make a round 
trip on the same airline and at the same fare code, there 
may be no need to read or analyze in detail the informa- 
tion associated with the outgoing round trip fares on the 
flight. 15 

Additional processing time can be saved if the user, 
through the travel policy, elects to eliminate round trip 
fares from consideration under certain circumstances. 
For example, since many round trip fares require the 
ticket to be purchased a certain number of days in ad- 20 
vance or require a stay over a Saturday night, the travel 
policy can choose to ignore round trip fares if the itiner- 
ary does not allow such limitations to be satisfied. These 
policy selections are used to determine the strategy that 
will be pursued for round trip fares in step 58. 25 

Once the last city pair is selected and the round trip 
strategy determined, flight information is retrieved 
from the remote data base for the selected last city pair. 
The loop consisting of steps 60, 62 and 64 retrieves the 
flight scheduling, fare, and fare limitation information 30 
for each city pair, in reverse travel order, for the flight 
origin and destination points entered by the operator. 
The system disconnects from the remote data base ser- 
vice, step 66, once flight information for each of the city 
pairs is retrieved. The flight information so retrieved is 35 
then analyzed in accordance with the travel policy 
stored within the local computer system, as will be 
described in detail below. 

The retrieve flight information step (step 60), is set 
forth in detail in FIGS. 4-7. As indicated in FIG. 1, 40 
scheduling information, fare information, and fare limi- 
tation information may be maintained separately and are 
typically accessed via separate information display 
screens. The first step in retrieving flight information is 
to query the data base for scheduling information, step 45 
68. The scheduling information retrieved is quickly 
checked for obvious errors, step 70. For instance, a city 
called from the scheduling data base that in fact has no 
airport, or has no service for a particular airport during 
a given time of the year, can be quickly screened, and 50 
further processing can be foregone. 

Scheduling information is typically presented in data 
screens made up of a plurality of lines of information. 
Once the scheduling information has been quickly 
scanned for errors, the information lines are processed 55 
one at a time, steps 72 and 74. Information received 
from the remote data base will include information on 
direct and connecting flights for any given city. If the 
travel policy maintained in the local computer terminal 
allows for a traveler to consider connecting flights (that 60 
is flights making up a city pair that require the traveler 
to change planes), the departure time, arrival time and 
other information for connecting flights are determined 
at step 76. 

The operator can specify whether flight schedules 65 
are to be retained based on departure time or arrival 
time. Test 78 of the flow chart directs flight departure 
time scheduling to steps 80 and 82, and directs flight 
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arrival time scheduling to steps 84 and 86. It will be 
understood that flights scheduled to leave within a spec- 
ified time range based around a desired departure or 
arrival time will be acceptable. 

Steps 80 and 82 respectively determine whether a 
particular flight is scheduled to leave earlier than or 
later than a desired departure time. Flights that are 
scheduled to leave earlier than the desired departure 
time range are rejected at step 80 on the premise that the 
traveler would not be able to make an earlier flight. 
Flights scheduled to leave after the desired departure 
time range are rejected at step 82 on the premise that the 
traveler is not willing to wait for the flight. 

Typical flight schedule data bases are not sorted by 
arrival times. Accordingly, when the operator has des- 
ignated the arrival time selection of flights, the schedul- 
ing data base must b sorted in a different manner than 
that described above for flight departure scheduling. In 
particular, at step 84, the program determines whether a 
particular flight called from the scheduling data base 
has a departure time after the desired arrival time, on 
the premise that any flights leaving the originating city 
after the time a traveler desires to be in his destination 
cannot possibly be applicable. Flights determined to 
have a departure time prior to the desired arrival time in 
test 84, are next analyzed at test 86 to determine 
whether the stated arrival time for the flight falls within 
the desired arrival time range. Flight information for 
flights selected to be within either the desired departure 
time range or the desired arrival time range is parsed 
and stored in the locally operated computer terminal, 
step 88, 

Flights determined to have a flight departure time 
later than the desired departure time range at step 82, 
and flights having a flight departure time later than the 
desired arrival time range (at step 84) are referred to test 
90 for analysis. Test 90 and step 92 comprise an auto- 
matic override step that enables the system to look at 
connecting flights if the original request entered by the 
operator was for direct flights only. Program flow is 
directed from test 90 to test 94 where it is determined 
whether there are any flights listed on the remote 
scheduling data base that fall outside the initially desig- 
nated time range (assuming no acceptable flights have 
yet been found). If there are no scheduled flights avail- 
able the program flow is directed to step 96, for record- 
ing of the time range examined, and return to step 62 of 
FIG. 3. Alternatively, program flow is directed to test 
98 if there are additional flights outside the initially 
established time range, where it is determined whether 
flight selection is being based on departure time or ar- 
rival time. Program flow is directed to step 100 if selec- 
tion is being based on departure time, where one hour is 
added to the time range, on the premise that a flight 
departing an hour after the desired departure time is 
preferable to a flight that leaves before the designated 
departure time. Program flow is directed from test 98 to 
step 102 if flight selection is being based on arrival time, 
where one hour is subtracted from the designated ar- 
rival time, on the premise that it is more preferable to 
arrive at a destination an hour before the preferred time 
rather than after the selected arrival time. Program flow 
is directed from step 100 or step 102 respectively back 
to step 72. 

Flight scheduling information pertaining to flights 
within designated departure or arrival times is parsed 
and stored at the local computer terminal (step 88). 
Program flow is next directed to test 104 to determine 
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whether the particular flight under analysis is a con- only fares, regardless of availability, are to be displayed, 
necting flight or not. Program flow for direct flights is Program flow is directed to step 126 to construct the 
directed to test 106 where it is determined whether the availability command if both fares and availability are to 
direct flight has intermittent stops (since not all direct be displayed. In this regard, it will be appreciated that a 
flights are nonstop flights) and whether the number of 5 particular flight may have a number of different fare 
stops is acceptable based on the travel policy. Program codes assigned to it by a particular carrier; reduced 
flow is directed from test 106 to step 72 for consider- fares may apply to only a certain number of seats within 
ation of the next flight schedule line, if the stops are a scheduled flight with the full fare applying to the 
unacceptable. Flights determined to be connecting remainder of the seats. Program flow is directed from 
flights at test 104 are referred to step 108 for parsing and 10 steps 124 or 126 to step 128 where the availability screen 
storing of the data pertaining to the additional connect- or fares screen respectively, as maintained in the remote 
ing flights that form the connection for the city pair data base, is presented in its entirety to the local com- 
(step 108). Program flow is then directed from test 108 puter terminal. Program flow is next directed to test 130 
to test 110 for a determination of whether the connect- where the determination of whether to present avail- 
ing stops are acceptable. Program flow is directed from 15 ability and fares or only fares is again made. Program 
test 110 to step 72 if the stops are unacceptable. flow is directed to test 132 if only fares for the particular 

Program flow is directed to step 112 from either test flight in question are to be considered and displayed. 
106 or test 110 for each flight which falls within the Test 132 determines whether there is in fact fare infor- 
departure or arrival time range being used, and which mation corresponding to the flight In schedule in the 
includes no stops, or stops that are acceptable. As will 20 remote data base. If there is no fare information avail- 
be appreciated, airline schedules are typically annotated able, program flow is directed to step 134 for so mark- 
in local time, as opposed to elapsed time. Time zone ing of the flight, and return to test 120 (FIG. 4). 
difference is therefore calculated at step 112 for the first Program flow is directed from test 130 to test 136 if 
flight found in a city pair. The time zone difference availability information is to be processed and dis- 
remains the same for all flights for each respective city 25 played. Test 136 determines whether the remote data 
pair, and can be used to easily calculate elapsed time for base has the ability to determine whether fare codes are 
subsequent flights found. Program flow is next directed still available. For instance some remote data bases 
to step 114 where any remark lines directly associated would have to inquire a third remote data base to deter- 
with flight scheduling information in the remote sched- mine the availability. In the same light, some small air- 
uling data base are processed and stored. 30 lines may not use computers, and availability informa- 

Program flow is next directed to test 116. Test 116 tion simply is not available. Program flow is directed 

queries the flight schedule information as to whether from test 136 to step 138, where the availability mode is 

the flight is on an airline to be excluded from consider- cleared when it is determined that there is no availabil- 

ation. For instance, the service on a particular carrier ity information available, and in this case, processing of 

may be unacceptable to the traveler, and flights on that 35 the flight is restarted at test 122 to gather only fare 

carrier can be excluded from consideration by the sys- infonriation for the flight. Program flow is directed 

tern. Program flow is directed from test 116 to step 72 to from test 136 to test 140 when availability information is 

call up the next schedule line to process if the flight available, for determination of whether the flight in 

analyzed at test 116 is for an unacceptable carrier. consideration is sold out or not operating. Program 

Program flow is directed to the retrieve fares step 118 40 flow is directed to step 134 for appropriate marking of 

for each schedule line that refers to a flight on an ac- the flight and return to step 120 of FIG. 4 if it is deter- 

ceptable carrier, that makes an acceptable number of mined that the flight is sold out or not operating, 
stops between city pairs, and which either departs or Once it is determined that there are fares for the flight 

arrives within an acceptable time range. Once the fares in question, program flow is directed to step 142 where 

for a particular flight are retrieved, program flow is 45 the flight/fare information is processed one line at a 

directed to test 120 where an arbitrary number of indi- time. Test 144 determines whether all lines of fare infor- 

vidual flight schedules to be considered can be set into mation have been analyzed. Program flow is directed to 

the program. For instance, rather than examine all pos- test 120 if all of the fare lines in the data base pertaining 

sible flights for a particular city pair, the system can be to the flight in question have been queried. Program 

programmed to stop looking for additional acceptable 50 flow is directed to step 146, if each of the fare lines have 

flights once, for example, five acceptable flights are not been queried, for determination of whether the 

found. Program flow is directed back to step 72 from current Une being processed has one-way and/or round 

test 120 if enough acceptable flights have not been trip fares within the fare line. In this regard, it will be 

found, and is directed to step 96 for return to the system appreciated that certain fare codes are specified by the 

sort and display step 48 if enough acceptable flights 55 airlines for use only in round trip situations. Program 

have been found, flow is directed to test 148 for determination of whether 

The retrieve fares step 118 is explained in greater the fare line under consideration contains only a round 

detail in conjunction with FIG. 5. As indicated in FIG. trip fare and the proposed flight origin and destination 

1, fare information is typically displayed separately points require a one-way trip. (For instance, when the 

from scheduling information by remotely accessed data 60 city pairs under consideration cannot be paired to form 

base services. The first step in the expanded retrieve round trips, only one-way fares need be considered.) If 

fares flow chart of FIG. 5 is the availability mode test the flight origin and destination points do call for a 

122. The operator of the program can specify whether one-way flight, and there are no one-way trip fares 

fare information only or both fare information and listed, program flows is directed by test 148 to step 142 

availability information for a particular flight is to be 65 for processing of the next fare line. Program flow is 

displayed, (Availability information states whether or directed from test 148 to step 150 for parsing and stor- 

not the fare is still available for booking.) Program flow age of the fare data from the fare line in question if there 

is directed to step 124 to construct the fares command if is one-way flight information available, or if the city 
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pairs allow a round trip flight and round trip data is 
shown. Program flow is then directed to step 152 for 
determination of fare availability, when the retrieve 
fares portion of the flow chart is being operated in the 
availability mode. In any case, program flow is directed 5 
to tests 154, 156, 158 for determination of whether the 
fare data located in the fare line under consideration 
meets certain travel policy criteria. 

Tests 154, 156, 158 are designed to quickly evaluate 
information that is readily discernable from the fare 10 
code line, without having to access the limitations data 
base. In this regard, it will be appreciated that fare 
limitations data bases are typically maintained in plain 
language, rather than code, and are time intensive to 
process and analyze. Test 154 quickly checks to see 15 
whether the fare class (i.e., economy, coach, first class) 
is acceptable in accordance with the travel request input 
by the operator. If the class is unacceptable the program 
is immediately directed to step 142 to process the next 
fare line from the remotely stored fares data base, 20 

Program flow is directed to test 156, if the fare class 
is satisfactory. Test 156 takes advantage of the fact that 
many fare codes are designed to reflect limitations for 
the fare. For example, an "X" followed by digits **X23" 
appearing in a fare code typically means that a fare 25 
designated by the fare code is good except on Tuesday 
and Wednesday. Other limitations that can be discerned 
directly from a fare code can be, for example, that the 
fare code is good only at a particular airport, or that 
advance purchase must be made 14 days or more prior 30 
to a flight. Test 156 directs program flow to the next 
available fare line if it can be discerned from the fare 
code that the fare in question is not acceptable. 

It will be recalled that the system analyzes the fmal 
leg, or city pair, of an itinerary first, and that each city 35 
pair is analyzed to determine whether it can be paired 
with another city pair so as to be viewed as part of a 
round trip. Test 158 is designed to save the system the 
time of accessing the remotely stored limitations data 
base if it is determined that the particular fare in ques- 40 
tion is not available, or if the fare line under consider- 
ation is for the second leg of a round trip fare. In the 
later case, the limitations data base will not be accessed 
for the particular fare until the system has determined 
the availability of a first leg of a round trip that can be 45 
matched with the fare code of the round trip second leg 
fare. It will be appreciated, in this regard, that the limi- 
tations associated with the first leg of the round trip 
apply to the entire round trip, and the limitations associ- 
ated with the second leg of the round trip do not have 50 
to be accessed. 

Program flow is directed to step 160 if the tests of 
154, 156 and 158 are successfully met. Step 160 takes 
advantage of the fact that a given fare code on a given 
airline between a given pair of cities will always be 55 
associated with the same list of limitations. The fare 
code being analyzed is compared to an "optimization 
list'* of fare codes that have already been encountered in 
the current processing session, as described below. If a 
fare code under consideration is found in the optimiza- 60 
tion list, there is no need to access the remote limitations 
data base. Test 162 routes the program flow around the 
retrieve and evaluate limitations step 164, in the event 
that the fare code under consideration is found in the 
optimization list. 65 

The retrieve and evaluate limitations step 164 pro- 
vides for the accessing of the remotely stored limita- 
tions data base, as explained in greater detail in FIGS. 6 
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and 7. Once the retrieve and evaluate limitation step is 
accomplished, program flow is directed to test 166. Test 
166 queries the limitation information retrieved in the 
retrieve and evaluate limitation step 164, to determine 
whether the fare line being analyzed is still acceptable, 
in light of the fare limitations, in accordance with the 
predetermined travel policy. If the fare limitations are 
not acceptable, program flow loops to step 142 for 
analysis of the next fare line. 

Program flow is directed to test 168 if the limitations 
for the fare line being analyzed are acceptable. Test 168 
analyzes the fare line to determine whether it pertains to 
a round trip. If the fare line being analyzed does pertain 
to a round trip, the program flow is directed to test 170 
to determine whether the fare code is a valid round trip 
fare code. In particular, if the fare being analyzed is for 
a return leg of a round trip, the fare code is assumed 
valid because the program has as yet not analyzed 
whether there is an acceptable outbound leg that can be 
joined with the return leg to complete a valid round 
trip. When the fare code being analyzed applies to an 
outbound leg of a round trip, the fare code being ana- 
lyzed for the outbound leg is valid only if the system has 
previously identified a return leg which can be matched 
with the outbound leg. Program flow is directed by test 
170 to step 142 if the fare code being analyzed is deter- 
mined to not be a valid round trip fare code. 

Program flow is directed to step 172 if the fare line 
being analyzed is not for a round trip, as determined by 
test 168, or if the fare code for the line being analyzed is 
a valid round trip fare code, as determined in test 170. It 
is not untypical for fare data contained within a re- 
motely stored fare data base to include both a one-way 
and round trip fare. The system, at step 172, splits the 
two fare prices into separate flight/fare structures, so 
the program can deal with the one-way cost and round 
trip cost separately. 

Program flow is next directed to test 174 where the 
number of fares already analyzed by the system is com- 
pared to a preset number to determine whether an ade- 
quate number of fares have been analyzed. Program 
flow is directed to test 120 of FIG. 4 if an adequate 
number of fares have been analyzed. Program flow is 
directed from test 174 to step 176 if more fares are to be 
analyzed. 

The retrieve and evaluate limitation step 164 of FIG. 
5 is set out in greater detail FIGS. 6 and 7. As discussed 
above, and with reference to FIG. 1, scheduling infor- 
mation, fare information, and fare limitations informa- 
tion are typically displayed separately by remote elec- 
tronic flight scheduling information services. Program 
flow, as described above, first determines which flight 
schedules are applicable to a proposed travel itinerary, 
and then determines which fare are acceptable for appli- 
cable scheduled flights. Fare limitations, that is, the 
requirements to be met for eligibility for a particular 
fare, are sometimes reflected in the fare code. More 
often, however, the fare limitation information for a 
particular fare is maintained in a separate limitations 
data base in plain English language entries. 

The fare limitations data base is queried for limita- ■ 
tions screens maintained therein in step 178 of FIG. 6. 
Step 180 scans through the header information of each 
limitation screen and then breaks the remaining text into 
individual limitations. The program flow is directed to 
step 182 for processing each of the limitations in serial 
order. Test 184 determines whether all of the limitations 
have been analyzed, and program flow proceeds to step 
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186 if there are more to process. Each Umitation is saved 
in step 186, to be incorporated into the optimization list 
referred to above in 160. The stored fare limitations are 
thereby available when the system processes other fares 
for the same airline on the same that include the same 5 
fare code, thereby circumventing the need to access the 
fare limitations data base more than once. 

The plain language limitations are scanned and 
parsed in step 188. The parsed limitations are grouped 
into general limitation types (categorizes of limitations, 10 
as advanced purchase or cancellation penalty limita- 
tions that can easily be referred to in the sort and display 
result step 48. Scanning and parsing can be accom- 
plished through well-known techniques such as recur- 
sive descent parsing with BNF parsing rules, or similar 15 
parsing technology. 

The scanned limitations are evaluated in step 190, as 
described in detail in conjunction with F 7. Test 192 
queries whether any of the Umitations in step 190 render 
the flight/fare alternative under consideration unavail- 20 
able (for instance, a limitation requiring travel on dates 
other than the planned travel date entered by the opera- 
tor), and directs program flow to test 166 of FIG. 5 to 
consider the next flight/fare alternative if a tested limi- 
tation renders the flight/fare alternative unavailable. 25 

Test 194 checks to see if the limitation type that was 
determined above is acceptable based on the travel 
policy. For instance, as part of the policy, the operator 
can say that "all fares with cancellation penalties are 
unacceptable", and similarly for other types of limita- 30 
tions. 

The term "applicability limitation" must be under- 
stood to understand the inquiry of test 187. Air fiight- 
/fare code limitations typically include limitations that a 
fare code is "only applicable on flight XY2". The same 35 
list of limitations for the same fare code may also in- 
clude a limitation that the fare is "only applicable on 
iflight ABC". It is understood in the industry, in this 
case, that either flight XYZ or flight ABC is acceptable. 
So-called "applicability" limitations will always test 40 
true in test 192, and will be saved, for comparison 
against subsequent applicability limitations found for 
the same fare code. 

Once each of the Umitations for the fare code have 
been analyzed, as determined by step 184, program flow 45 
is directed to test 187. Test 187 determines whether an 
applicability limitation for the fare code being analyzed 
was found. If no applicability limitations were found, 
the program flow is directed to test 166 of FIG. 5, re- 
turning "true"; that is, no unacceptable limitations were 50 
found. Program flow is directed to test 189 if applicabil- 
ity limitations were found, to determine whether any of 
the applicability limitations are acceptable. The pro- 
gram flow is directed to test 166 of FIG. 5 with a "true" 
result if the applicability limitations are acceptable, or 55 
returns "false" if the acceptability limitations are not 
acceptable. 

The evaluate limitations step 190 is depicted in 
greater detail in FIG. 7. The scan limitation step 188 of 
FIG. 6 reduces each of the plain language limitations 60 
into an idendfiable code. Step 196 reviews the code 
generated by the scan limitation to determine what type 
of limitation has been analyzed. Depending on whether 
the limitation is an applicability limitation, reserve limi- 
tation, purchase Umitation, travel limitation, stay limita- 65 
don, or penalty limitation, the program flow is directed 
to step 198, 200, 202, 204, 206, or 208 accordingly. The 
evaluation process compares the limitation text against 
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the travel circumstances to determine whether a limita- 
tion excludes the particular flight/fare combination in 
consideration. Note that step 198 includes the steps of 
210, 212 and 214 to save whatever applicability rules 
have been found for analysis of the applicability rules in 
accordance with the steps described above in conjunc- 
tion with FIG. 6. 

The process described above defines and ascertains a 
plurality of flight/fare alternative from the remotely 
accessed flight information data base. That is to say, 
each fare for each flight that is determined to be accept- 
able comprises a flight/fare alternative structure as 
presented to the locally operated computer system at 
the locally operated computer terminal 22. It is to be 
understood that a single flight may have several differ- 
ent valid flight/fare alternative structure, since different 
fares may apply to a single flight. 

Once each of the flight/fare alternative structures is 
ascertained from their remote data base, communica- 
tions with the remotely accessed data base are termi- 
nated. The system then proceeds to step 48, the sort and 
display results step, for determination of which of the 
acceptable flight/fare alternatives are the most prefera- 
ble in accordance with the previously determined travel 
policy. A scored and sorted display of each of the flight- 
/fare alternative structures for each city pair is pres- 
ented to the operator. 

The sort and display step 48 is set forth in detail on 
FIGS. 8 through 10. Each flight/fare alternative is 
assigned an initial score equal to the dollar value of its 
fare, step 216. Program flow is next directed to step 218 
where the initialized score value is modified in accor- 
dance with predetermined travel policy factors. The 
scoring process of step 218 is set forth in greater detail 
in FIG. 9, described in detail below. . Once scored, the 
flight/fare alternatives are sorted by score value, step 
220. 

The scored and sorted flight/fare alternatives can be 
displayed for auditing purposes, or for flight selection 
purposes. Test 222 directs program flow to the summa- 
rize itinerary step 224 and display summarized itinerary 
step 226, when auditing is desired, and to step 228 when 
the auditing display is not selected. The flight/fare al- 
ternative structures are displayed for the first city pair 
in sorted order at step 228, and, on command, the flight- 
/fare alternatives for the city pairs in the travel itinerary 
are displayed at step 230. 

The generate score value step 218 is described in 
greater detail in conjunction with FIG. 9. As described 
above, certain travel policy items are used to com- 
pletely eliminate a flight/fare alternative from consider- 
ation. For instance, if a particular travel policy states 
that no flight requiring 14 day advance booking will be 
considered, flights having flight/fare codes requiring 14 
day advanced booking will be screened during the sys- 
tem connect to remote data base and read information 
step 46. Flight/fare structures that are not so screened 
are ranked by relative merit. Step 218 takes each of the 
flight/fare alternatives that passes initial screening, and 
scores each flight/fare structure according to the prede- 
termined, stored travel policy. In particular, each flight- 
/fare structure is scored with reference to elapsed flight 
time, ground transportation costs associated with the 
particular flight, particular airline preference, route 
preference, and preweighted scoring of various flight- 
/fare limitations. 

The first city pair having flight/fare alternatives to be 
scored is chosen in step 232. The shortest elapsed flight 
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time (e;„/n) of all the flight/fare alternatives presented assigned preference value is subtracted from the flight- 
for a particular city pair is determined in step 234. Once /fare alternative score to indicate that the flight/fare 
emin is determined, program flow is directed to step 236 alternative under consideration is a preferred route, and 
to select the first flight/fare alternative for the city pair should be given preference in the selection of a flight- 
under consideration. 5 /fare alternative. 

The initialized score (pertaining to the raw dollar fare Program flow is next directed to steps 248 and 250 for 

value) for the first flight/fare alternative is readjusted in selection of the next flight/fare alternative to be scored, 

step 238 to account for elapsed flight time consider- and is directed to steps 252, 254 for selection of the next 

ations. In particular, the difference between the elapsed city pair to be scored. Program How is redirected to 

flight time of the flight/fare alternative under consider- 10 step 220 of FIG. 8 when each flight/fare alternative for 

ation and Cnin is multiplied times a preassigned hourly each city pair has been scored. 

rate for the traveler's time. For instance, if a particular jhe scoring process outlined above in connection 

flight/fare alternative is a longer flight than the shortest ^vith FIG. 9, provides a score value for each separate 

flight by half an hour, and the traveler's flight time was night/fare alternative in each city pair of the itinerary, 

evaluated at $50 an hour, a value of S25 would be added 15 ^he scored flight/fare alternatives are presented to the 

to the flight/fare alternative's initialized score. operator of the computer terminal 22 for selection of 

Program flow is next directed to step 240, where ^he desired travel itinerary. Although scoring is done on 

adjustment is made to the flight/fare alternative score in ^^^^ flight/fare alternative, for each city pair, the oper- 

accordance with any limitations associated with the ^^^^ ^^^^^^ ^- ^ ^ ^^^^^^ ^^^^ 3^^^ flight/fare 

flight/fare alternative. For instance a travel pohcy 20 alternative from each city pair to obtain the overall best 

decision may be made that is acceptable to have a mini- j^j^ ^^^^ ^^^^^ ^^^^^ ^^^.^^^j 

mum stay imitation on a flight, but that i would be ^.^^^^ considerations must be met to comply with eligi- 

preferable to pay a certain percentage greater fare if a ^^^^^ ^^/and 226 of 

flight/fare alternative were available that didn't have a ttt/- o j r • i j . • r 

stay Hmitation associated with it. The fare of the flight- 25 ^^^'J P^^^^^^. ^ "^f^"^ for mcludmg round trip fare 

/fare alternative is multiplied by the preassigned per- ^o^^^^^^fons m selecting the flight/fare alternative 

centage value for the limitation, with the result added to ^''^ f'' ^^^"^^^^y- 

the score value selection of flight/fare alternatives allows the sys- 

Program flow is next directed to step 242, where tern to display a recommended fare for the entire itiner- 

ground transportation costs associated with a particular 30 ^ry which is useful for auditing travel that has been 

flight/fare alternative are taken into consideration. Step ^^f^^^ other sources. 

242 is based on the premise that most business travelers ^" particular, the auditing process is begun at step 256 
going to a particular city will have a usual place of selecting the first city pair. Each flight- 
business within the city traveled to. Certain cities, such /^^^^ structure for the city pair is analyzed in the loop 
as Chicago, have multiple airports, and certain metro- 35 consistmg of step 258, 260 and 262 to find the best scor- 
politan areas, such as New York City, are serviced by ^"S one-way fare that is available for booking. Once 
different airports in different cities. The cost of ground determined for all city pairs, program flow is directed 
transportation from any one of the alternative airports ^^^m test 260 to step 264 where each of the city pairs is 
in a given city to the traveler's usual place of business ^Sain selected for consideration in terms of round trip 
can be taken into consideration when evaluating differ- 40 ^^^^s. Test 266 makes the determination of whether the 
ent flight/fare alternative structures by adding the cost ^^^^ scoring alternative that is available for booking for 
of ground transportation to the initialized score value ^^^V P^^^' which could be based on either a one-way 
for the particular flight/fare alternative. ^^^^^ t"p fare, is in fact based on a round trip fare. 

Program flow is next directed to step 244 where the Program flow is directed from test 266 to test 268 if the 

scoring process takes into consideration a preference 45 ^^st flight/fare alternative is in fact a round trip fare, 

for a particular airline. For example, a company may T'^st 268 makes the determination of whether the total 

negotiate a contract with an airline for a certain percent round trip fare is lower than the sum of the fares for the 

reduction of all flights flown by its personnel on the flight/fare alternatives that have already been identified 

particular airline, or it may be a company policy to for the two city pairs in the round trip. If the answer is 

prefer a particular airline for its service or incentive 50 V^s, the round trip alternative is selected as the best 

program. The preference may be stated in either a set flight/fare alternative for both of the city pairs in step 

**airline preference value" or may be stated as a certain 270. 

percentage of the fare. 244 subtracts from the flight/fare Program flow is directed from test 266 or 268 respec- 

alternative score either the set preference dollar value, lively to test 272, if the best scoring flight/fare alterna- 

or the percentage of the fare value, when the flight/fare 55 tive for a city pair is based on a round trip fare, or if the 

structure is for an airline that has been designated as a total round trip fare is not lower than the sum of the 

preferred airline. fares for the flight/fare alternatives already identified 

Program flow is next directed to step 246 where the for the city pairs. Program flow loops back to test 266 

flight/fare alternative under consideration is evaluated for selection of the next city pair via step 274 if there are 

in terms of whether it is on a preferred route. Similar to 60 more city pairs to consider, 

the airline preference consideration above, a company We claim: 

may be in a position to negotiate a special price for is 1. A system for providing a plurality of alternative 

personnel traveling on a particular flight or on a partic- travel itineraries ranked in order of preference in accor- 

ular route. The departure airport, the arrival airport, the dance with previously stored travel policy data, com- 

airline to be flown and the flight number can all be 65 prising: 

designated as part of a preferred route, with either a set means for accessing a data base comprising travel 

money value or a percentage of the fare value assigned data including separately maintained travel sched- 

to indicate a preference for the preferred route. The ule data items, fare data items, and fare limitation 
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information, said travel schedule data items includ- 
ing arrival and departure information; 
means for processing said travel data including — 
means for merging selected ones of said travel sched- 
ule data items with applicable ones of said fare data 5 
items to create a plurality of schedule/fare data 
items; 

means for evaluating each schedule/fare data item in 
accordance with said fare limitations information 
to provide said plurality of alternative travel itiner- 10 
aries; 

means for scoring individual ones of said alternative 
travel itineraries with a relative score in accor- 
dance with said travel policy; and 

means for displaying said alternative travel itineraries 
as scored in accordance with said travel policy. 

2. The invention as claimed in claim 1, said travel 
schedule data items including data on scheduled trips of 
available transportation carrier, said means for process- 
ing said travel data including means for selecting a de- 
parture point and an arrival point to create at least one 
city pair, said means for processing said travel data 
further including means for identifying said scheduled 
trips extending between said city pairs. * ^5 

3. The invention as claimed in claim 1, said data on 
scheduled trips including data on direct trips and con- 
necting trips, said means for processing said travel data 
including means for selectively excluding the process- 
ing of data on said connecting trips. 

4. The invention as claimed in claim 3, said means for 
processing said travel data including means for auto- 
matically including the processing of data on said con- 
necting trips when there are no direct trips found in said 
data base. 35 

5. The invention as claimed in claim 2, said travel data 
including data on departure times of said scheduled 
trips, said means for creating said travel itineraries in- 
cluding means for specifying a departure range of ac- 
ceptable departure times, said means for processing said 4Q 
travel data including means for identifying said sched- 
uled trips between said city pairs having departure 
times within said departure range, 

6. The invention as claimed in claim 5, said means for 
processing said travel data including means for auto- 45 
matically expanding said range of acceptable departure 
times if no scheduled trips between said city pairs hav- 
ing departure times within said specified departure 
range are found in said data base. 

7. The invention as claimed in claim 2, said travel data 50 
including data on arrival times of said scheduled trips, 
said means for creating said travel itineraries including 
means for specifying an arrival range of acceptable 
arrival times, said means for processing said travel data 
including means for identifying said scheduled trips 55 
between city pairs having arrival times within said ar- 
rival range. 

8. The invention as claimed in claim 7, said means for 
processing said travel data including means for auto- 
matically expanding said range of acceptable arrival 60 
times if no scheduled trips between said city pairs hav- 
ing arrival times within said specified arrival range are 
found in said data base. 

9. The invention as claimed in claim 2, said means for 
creating travel itineraries including means for automati- 65 
cally excluding the selection of scheduled trips associ- 
ated with predetermined ones of said transportation 
carriers. 



10. The invention as claimed in claim 2, said means 
for creating said travel itineraries including means for 
determining when a predetermined number of travel 
itineraries have been created, and discontinuing the 
creation of additional travel itineraries when said prede- 
termined number has been reached. 

11. The invention as claimed in claim 2, said travel 
fare data items including data on the fares for said 
scheduled trips, said means for processing said travel 
data including means for identifying the individual fares 
applicable to said scheduled trips extending between 
said city pairs. 

12. The invention as claimed in claim 11, said data 
base including data on the availability of the fares iden- 
tified for said scheduled trips extending between said 
city pairs, said means for processing said travel data 
including means for selectively excluding the further 
processing of travel data pertaining to scheduled trips 
identified as having unavailable fares. 

13. The invention as claimed in claim 11, each of said 
fares being presented in coded form to reflect limita- 
tions on the availability of individual fares, said means 
for processing said data including means for discerning 
said limitations from said codes and discounting the 
processing of fares that have unacceptable limitations. 

14. The invention as claimed in claim 11, said travel 
data including fare limitation data reflecting limitations 
on the applicability of said fare data, said means for 
processing said travel data including means for identify- 
ing the fare limitations applicable to said fares. 

15. The invention as claimed in claim 14, said fare 
limitations data being presented in plain language, said 
means for identifying the fare limitations including 
means for scanning and parsing said plain language. 

16. The invention as claimed in claim 14, said means 
for processing said travel data including means for se- 
lectively excluding the further processing of travel data 
pertaining to scheduled trips having unacceptable fare 
limitations. 

17. The invention as claimed in claim 2, said data base 
including data on intermediate stops of individual 
scheduled trips between said city pairs, said means for 
processing said travel data including means for selec- 
tively excluding the further processing of travel data 
pertaining to scheduled trips identified as having more 
than a predetermined number of intermediate stops. 

18. The invention as claimed in claim 1, said data base 
comprising a remotely maintained data base, said means 
for processing said travel data including means for tem- 
porarily locally storing selected data obtained from said 
remote data base, said means for accessing said data 
including means for operably connecting said process- 
ing means and said remote data base for transfer of said 
selected data to said processing means, and for discon- 
necting said processing means from said remote data 
means when said selected data is locally stored. 

19. The invention as claimed in claim 1, said means 
for scoring including means for assigning an initial score 
to each of said travel itineraries reflecting the monetary 
value of its fare. 

20. The invention as claimed in claim 1, said means 
for scoring individual means for adjusting said scores to 
reflect elapsed travel time for respective individual 
itineraries. 

21. The invention as claimed in claim 1, said means 
for scoring mdividual means for adjusting said score to 
reflect a predetermined carrier preference. 
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22. The invention as claimed in claim 1, said means 
for scoring including means for adjusting said score to 
reflect a predetermined route preference. 

23. The invention as claimed in claim 1 said means for 
scoring including means for adjusting said score by a 5 
predetermined amount in accordance with fare limita- 
tions associated with respective individual travel itiner- 
aries. 

24. A method for providing a plurality of alternative 
travel itineraries ranked in order of preference in accor- ^0 
dance with a previously determined travel policy, com- 
prising: 

accessing a data base comprising travel data including 
separately maintained travel schedule data items, 
fare data items, and fare limitation information, said 
travel schedule data items including arrival and 
departure information; 

processing said travel data to include the steps of— 

merging selected ones of said travel schedule data 
items with applicable ones of said fare data items to 
create a plurality of schedule/fare data items; 

evaluating each schedule/fare data item in accor- 
dance with said fare limitations^ information to pro- 
vide said plurality of alternative travel itineraries; 

scoring individual ones of said alternative travel itin- 
eraries with a relative score in accordance with 
said travel policy, and 

displaying said alternative travel itineraries as scored 
in accordance with said travel policy. 

25. The invention as claimed in claim 24, said travel 
data including data on scheduled trips of available trans- 
portation carriers, said step of processing said travel 
data including the step of selecting a departure point 
and arrival point to create at least one city pair, said 35 
processing of said travel data further including the step 
of identifying the scheduled trips extending between 
said city pairs. 

26. The invention as claimed in claim 25, said data on 
scheduled trips including data on direct trips and con- 4Q 
necting trips, the processing of said travel data includ- 
ing the step of selectively excluding the processing of 
data on connecting trips. 

27. The invention as claimed in claim 26, the process- 
ing of said travel including the step of automatically 45 
processing data on connecting trips when there are no 
direct trips found in the data base. 

28. The invention as claimed in claim 25 said travel 
data including data on departure times of said scheduled 
trips, the step of creating said travel itineraries including 50 
the step of specifying a departure range of acceptable 
departure times, the processing of said travel data in- 
cluding the step of identifying scheduled trips between 
city pairs that have departure times within said depar- 
ture range, 55 

29. The invention as claimed in claim 28, the process- 
ing of said travel data including the step of automati- 
cally expanding the range of acceptable departure times 
if no scheduled trips between city pairs having depar- 
ture times within the specified departure range are 60 
found in the data base. 

30. The invention as claim in claim 25, said travel data 
including data on arrival times of said scheduled trips, 
the step of creating said travel itineraries including the 
step of specifying an arrival range of acceptable arrival 65 
times, the processing of said travel data including the 
step of identifying scheduled trips between city pairs 
having arrival times within said arrival range. 



31. The invention as claim in claim 30, the processing 
of said travel data including the step of automatically 
expanding the range of acceptable arrival times if no 
scheduled trips between city pairs having arrival times 
within the specified arrival range are found in the data 
base. 

32. The invention as claimed in claim 25, the step of 
creating said travel itineraries including the step of 
automatically excluding the selection of scheduled trips 
associated with predetermined ones of said transporta- 
tion carriers. 

33. The invention as claimed in claim 25, the step of 
creating said travel itineraries including the step of 
determining when a predetermined number of travel 
itineraries have been created, and discontinuing the 
creation of additional travel itineraries when the prede- 
termined number has been reached. 

34. The invention as claimed in claim 25, said fare 
data items including data on the fares for said scheduled 
trips, the step of processing said travel data including 
the step of identifying the individual fares applicable to 
said scheduled trips extending between said city pairs. 

35. The invention as claimed in claim 34, the data base 
including data on the availability of the fares identified 
for said scheduled trips extending between said city 
pairs, the step of processing said travel data including 
the step of selectively excluding further processing of 
travel data pertaining to scheduled trips identified as 
having unavailable fares. 

36. The invention as claimed in claim 34, each of said 
fares being presented in coded form to reflect limita- 
tions on the availability of individual pairs, the step of 
processing said data including means for discerning said 
limitations from said codes and discounting the process- 
ing of fares that have unacceptable limitations. 

37. The invention as claimed in claim 34, said travel 
data including fare limitation data reflecting limitations 
on the applicability of said fare data, the step of process- 
ing said travel data including the step of identifying the 
fare limitations applicable to the fares. 

38. The invention as claimed in claim 37, said fare 
limitations data being presented in plain language, the 
step of identifying the fare limitations including the step 
of scanning and parsing the plain language. 

39. The invention as claimed in claim 38, the step of 
processing said travel data including the step of selec- 
tively excluding the further processing of travel data 
pertaining to scheduled trips having unacceptable fare 
limitations. 

40. The invention as claimed in claim 25 the data base 
including data on intermediate stops of individual 
scheduled trips between said city pairs, the step of pro- 
cessing said travel data including the step of selectively 
excluding the further processing of travel data pertain- 
ing to scheduled trips identified as having more than a 
predetermined number of intermediate stops. 

41. The invention as claimed in claim 24, said data 
base comprising a remotely maintained data base, the 
step of processing said travel data including the step of 
temporarily storing selected data obtained from said 
remote data base in a local data base, the step of access- 
ing said data including the step of transferring said se- 
lected data from the remote data base to the local data 
base for local processing of said travel data. 

42. The invention as claimed in claim 24, the step of 
scoring said proposed travel itineraries including the 
step of assigning an initial score to each of said travel 
itineraries reflecting the monetary value of its fare. 
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43. The invention as claimed in claim 24, the step of 
scoring said travel itineraries including the step of ad- 
justing said score to reflect elapsed travel time for re- ^ 
spective individual itineraries. 

44. The invention as claimed in claim 24, the step of 
scoring said travel itineraries the step of adjusting said 
score to reflect a predetermined carrier preference. 10 

45. The invention as claimed in claim 24, the step of 
scoring said travel itineraries including the step of ad- 
justing said score to reflect a predetermined route pref- 
erence. 



357 
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46. The mvention as claimed in claim 24, the step of 
scoring said travel itineraries including the step of ad- 
justing said score to reflect elapsed travel time. 

47. The invention as claimed in claim 24, the step of 
scoring said travel itineraries the step of adjusting said 
score by a predetermined amount in accordance with 
fare limitations associated with respective individual 
travel itineraries. 

48. The invention as claimed in claim 24, including 
the step of compiling an optimization list of pertinent 
fare limitations information as said fare limitations are 
retrieved from said data base whereby subsequent 
schedule/fare data items may be evaluated in accor- 
dance with said optimization list without accessing said 
data base for said fare limitations information. 

* * * * « 
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UNITED STATES PATENT AND TRADEMARK OFFICE 

CERTIFICATE OF CORRECTION 



It h certified that error appears in the above-identified patent and that said Letters Patent is hereby 
corrected as shown below: 



Column 4, line 17, delete the word "b" 
and substitute therefor — be — . 

Column 6, line 64, delete the word "flows" 
and substitute therefor — flow — . 

Column 9, line 5, delete the words "same 
that" and substitute therefor — same route 
that — . 

Column 9, line 11, delete the word "as" 
and substitute therefor — such as — . 

Column 9, line 11, delete the word "limita- 
tions" and substitute therefor — limita- 
tions) — • 

Column 9, line 10, delete the word "cate- 
gorizes" and substitute therefor — cate- 
gories--. 

Column 9, line 18, delete the words "F 
7" and substitute therefor — Fig. 7 — . 
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It is certified that error appears in the above-identified patent and that said Letters Patent is hereby 
corrected as shown below: 



Column 10, line 9, delete the words "alterna- 
tive from" and substitute therefor — alterna- 
tive structures from--. 

Column 10, line 16, delete the word "struc- 
ture," and substitute therefor 
— structures , . 

Column 10, line 46, delete the words "the 
city" and substitute therefor — the other 
city — . 

Column 10, line 53, delete the word "flight" 
and substitute therefor — flights — . 

Column 14, line 24, delete the word "discount- 
ing" and substitute therefor — discontinu- 
ing — . 

Column 14, line 63, delete the word "individ- 
ual" and substitute therefor --including — . 

Column 14, line 63, delete the word "scores" 
and substitute therefor — score — . 

Column 14, line 67, delete the word "individ- 
ual" and substitute therefor — including — . 
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DATED : August 29, 1989 ^ 
INVENTOR(S) : Mark L. Ahlstrom et al. 

It is certified that error appears in the above-identified patent and that said Letters Patent is hereby 
corrected as shown below: 



Column 15, line 45, delete the words "travel 
including" and substitute therefor — travel 
data including — . 

Column 15, line 62, delete the words "as 
claim" and substitute therefor — as claimed — . 

Column 16, line 1, delete the words "as 
claim" and substitute therefor — as claimed — * 

Column 16, line 34, delete the word "discount- 
ing" and substitute therefor — discontinu- 
ing — . 

Column 17, line 8, delete the words "itiner- 
aries the" and substitute therefor — itiner- 
aries including the — . 
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It is certified that error appears in the above-identified patent and that said Letters Patent is hereby 
corrected as shown below: 

Column 18, line 4, delete the words "itiner- 
aries the" and substitute therefor --itiner- 
aries including the--. 



Signed and Sealed this 
Eleventh Day of September, 1990 



Attest: 

HARRY F. MANBECK. JR. 
Attesting Officer Commissioner of Ftueias ami Thulemarks 
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